Cisco Systems: Implementing "Customized" ERP in Nine Months and within Budget

De Marco once said that what cannot be measured cannot me managed. Academicians and practitioners in the field of software engineering and information systems project, have consistently cited “intangibility” of software leads to stakeholder conflicts and lack of top management support resulting in the failure of over 75% of Information Systems Projects. Cost overruns and delayed delivery not only led to calling back of some projects but also yielded some catastrophic results. ERP packages, despite their known upsides, has their own shortcomings in terms of feasibility and scalability of the system to match the requirement of the customers. Cisco’s skepticism toward an ERP system was well grounded. But instability and regular outages of their existing system with its inability to support growing needs of the company left them with no choice. This case details how Cisco consolidated a team comprising of its own members, KPMG and Oracle mixed the robustness of sequential life cycle model with the flexibility of the iterative prototyping model to come up with a working system within just 9 months. This case also embarks on the top management support that Cisco received from the beginning of the project. In most cases, Information Systems development projects do not receive a conducive culture from the top management. Further the teams from Cisco, KPMG and Oracle blended into one cohesive unit with a common objective. Finally, the case ends with throwing a debatable question whether the success of Cisco can be repeated, asking whether Cisco was advantaged by technical resources and key timings. Lessons learned contains summaries of the major success drivers and flaws in place, which contributed to the successful rollout of Cisco’s 15 million dollar ERP project in only nine months. Introduction Cisco Systems, Inc. perhaps the biggest name in the data communication business had only one keystone productits router. Two Stanford computer scientists founded the company in 1984. Unbelievably by 1997, Cisco became a fortune 500 company and in the following year Cisco’s market capitalization was over $100 billion dollars. To keep pace with its gigantic growth, Cisco needed to look into their future regarding their existing Information Systems. Unreliability and regular outages brought into question the soundness of trying to modify the current system to meet the Cisco’s constantly growing needs. The current system was a UNIX-based software package that supported financial, manufacturing, and orderentry systems. An upgrade was made available to Cisco, but was a solution that offered more reliability and redundancy without maintainability or room for growth. Pete Solvick CIO of Cisco did not initially wanted to undertake a huge company wide ERP project, but in January of 1994, a system failure halted nearly the entire business for two days, and the problem could no longer be ignored. Avimanyu Datta prepared this case mainly for his research work on organizational self-renewal and ambidextrous structure. In addition, this case can be purpose of classroom discussion. 1 Data redundancy and redundant servers and clients are required against outages. Copyright © 2005 Avimanyu Datta. Page 1 Case Prepared by Avimanyu Datta, Team Leader, ICFAI Business School Research Center Solvick, along with other managers put together a plan to take on replacement of all faulty legacy applications in a single ERP project that would provide a common data architecture throughout each business unit. The analysis below will describe in detail the points of their implementation approach, why the project was successful, whether the success was “smart” or “lucky” (or a combination of both), and the possibility of other companies’ ability to replicate Cisco’s ERP implementation technique. Background Cisco Systems, Inc. was founded by two computer scientists from Stanford, in 1984 and became publicly traded in 1990. The company’s primary product was the ‘router’ that controlled the flow of data between the complex TCP/IP networks that made up the Internet and corporate Intranets. With the rise in the use of the Internet after 1990, demand for Cisco’s products increased heavily. By 1997, Cisco was ranked among the top five companies in return on revenues and returns on assets. In the same year Cisco entered the Fortune 500 and reached a market capitalization over $100 billion. Don Valentine, partner of Sequoia Capital and vice chairman of the board of Cisco, was the first to take initiative and pave the path for the young company, which went on to savor huge success. It started in 1988, with John Morgridge, who was an experienced executive in the computer industry, being appointed as CEO. Morgridge’s first effort was to build a professional management team. But, the management team clashed with the founders of Cisco systems, which resulted in departure of the founders after the company’s initial public offering, in 1990. This eventually, enabled CEO Morgridge to implement an extremely disciplined management structure, within Cisco. He maintained a centralized functional organization that continued approximately the next ten years. In the beginning of 1993, Cisco was a $500 million company, supported by a UNIXbased software package to conduct its core transaction processing tasks. The package supported the functional areas of the company like, finance, manufacturing, and order entry. It was at this time, Pete Solvik joined Cisco, as CIO. He analyzed the current UNIX-based software package, which was being used, and found that it did not provide the degree of redundancy, reliability, and maintainability that Cisco needed to keep up with their current business trends. Even an up-gradation from their current software vendor, could not suffice for their changing needs. The management structure in 1993 provided that each functional business unit make its own decisions regarding the future of their IT systems. IT representatives from each department were asked to report the expenses to Slovik, who maintained a strict management structure in each department. Each department head knew that “band-aiding” the current system was not going to be sufficient to keep up with the company’s rapid growth. However, no individual was willing to approach the board with a costly and lengthy proposal for replacement of the legacy systems. 2 The most commonly used Network Architecture. TCP stands form Transmission Comtrol Propocol. IP Stands for Internet Protocol. The architecture was founded by the Department of Defense, USA. Copyright © 2005 Avimanyu Datta. Page 2 Case Prepared by Avimanyu Datta, Team Leader, ICFAI Business School Research Center Failure of the Existing System Solvik’s initial intention was to avoid an ERP solution, which too long to implement and involved tremendous expenditures. In addition, each department was independent of the other, which was contrary to organizational structure supported by ERP system. Thus, Slovik planned to let each functional area within Cisco make its own decision regarding the software application that they wanted to use. However, all functional areas were required to use a common architecture and database, to maintain standardization within the company. The year that followed, saw little change in the software support system at Cisco. None of the departments actually got itself, a new and updated package. Instead, they kept on operating by fixing the existing systems and somehow managed to carry on. In late 1993, Randy Pond, Senior VP operations at Cisco confirmed that the fixing the existing system was pointless as it would not serve the growing needs of the firm. Finally, in January 1994, Cisco’s legacy environment failed entirely, resulting in a shortcoming that could no longer be ignored. There was a company wide shut-down for almost two days. A number of managers at Cisco came to the conclusion that the autonomous approach to systems replacement that they had adopted, would not succeed any more. The System Replacement At the point of crisis, Carl Redfield, the senior vice-president of manufacturing took the lead in getting a single integrated replacement of all the applications at Cisco, instead of investing longer time, in trying to integrate separate projects in the different functional areas. Thus, a team was formed to investigate the best possible replacement for the existing software support system. The factors that would govern the implementation of the new system were decided to be less time, low customization, and high priority. The company had two options available to it: 1. Purchase a single ERP system, which would be expensive to procure, time consuming to implement and would replace each department’s autonomous structure. 2. Upgrade the existing legacy system, built to support s $300 million Company, which Cisco no longer was. With the need for a much larger system for its growing needs, Cisco chose to purchase a single ERP. 3 Selection of Partnering Consultant and a Vendor Cisco’s management team realized from the beginning that implementing an enterprise wide system to meet the business needs of the company would require heavy involvement from the business people in the company, along with people from the IT department. Their team selection policy not only included the best people from these two departments, but the most competent people from every department in the company, who were hand-picked to be part of the ERP implementation team. This was defined by 3 The entire project management of Cisco from selection of partners to Implementation of the prototypes is put on Exhibit 5. Copyright © 2005 Avimanyu Datta. Page 3 Case Prepared by Avimanyu Datta, Team Leader, ICFAI Business School Research Center the team management, as the critical factor in the success of the team. The next step that Cisco took was to involve a consulting partner to aid in the implementation process. Cisco was looking for a partner who would, in addition to providing consulting services would also help Cisco to choose the ERP vendor. Only, KPMG consulting only agreed to provide such support. KPMG consulting joined Cisco at this stage with their great technical skills, and expert business knowledge. KPMG appeared to be an ideal partner a Cisco because they were willing to give them the expert resources that Cisco required to complete such a large project in as short a time as possible. The consulting form sent their best ERP Implementation program manager, Mark Lee. Under Lee’ leadership, 20 member team from Cisco evaluated the available software packages in the market. Ten days were spent drafting the ERP Request for Proposal (RFP). The team targeted on two prime packages, within little more than a week. They had used the knowledge of large corporations, and research sources like Gartner to know the most preferred option among other users in the market. Over the one month, Cisco and KPMG went through a rigorous process of selecting the right option from the two narrowed choices. Oracle was chosen in the end due to their better manufacturing capability than the other vendor, the promises of long-term functionality development, and their geographical closeness to Cisco. Oracle was particularly motivated to make the Cisco project a success. The Cisco project would be a first major implementation of a new release of the Oracle ERP product. Oracle had to prove their point that their new product had major improvements in support of manufacturing. A successful implementation at Cisco would launch the new product on a very favorable trajectory. Having so much at stake forced Oracle to put a large amount of resources and some of their best people on the project to guarantee its success. The contract itself reflected Oracle’s commitment by promising capabilities, not simply a software package. In addition Cisco agreed upon helping Oracle to market their latest newest releases to potential customers, should Oracle be successful in delivering the system in time and budget. Here Oracle was getting a service that it needed to have far more than Cisco needed to give. This gave Cisco a huge bargaining power, something it could not have had with SAP. Exhibit 1 gives a comparative analysis of SAP, PeopleSoft and Oracle. Setting up the Budget and Schedule It took the Cisco team only 75 days, from analyzing the problem, to the final selection the vendor and finalizing the schedule and budget. From the initial conception of the project, its leaders Solvick, Pond, and Redfield knew what they wanted; a large system in a short amount of time that contained the ability to adapt and grow concurrently with their business, and a provider that was going to be around to support their product well into the future. The decisiveness of the leaders on what they wanted pushed the selection process forward in a short amount of time. Senior management fully backed the project, and was kept informed on every step. From the very beginning, a strong schedule and the backing of the entire corporation helped to insure success of the project. 4 Other consulting partners considered then were Cap Gemini Sogeti, Siemens, IBM, PriceWaterhouse Coopers. Ernst & Young and Cap Gemini Sogeti later merged to became Cap Gemini Ernst & Young 5 The KPMG Consulting division now is named as Bearing Point Copyright © 2005 Avimanyu Datta. Page 4 Case Prepared by Avimanyu Datta, Team Leader, ICFAI Business School Research Center They had not gone through formal processes of management approval, which further sped up the implementation. At this stage, the board of directors at Cisco were concerned with how long the project would take and how much would it cost. A gigantic project such as this, often consumes a huge amount of resources, spins out of control, and delivers substandard results in the end. The Cisco team, after much debate, committed to do the entire process within nine months and for $15 million. Cisco did not attempt to do a formal economic justification for the costs to be incurred in this project. They looked upon it to ‘institutionalize a business model for the organization’. It was the single largest capital project ever approved by the company. Managing the implementation team Cisco expanded its team from its core 20 to a 100 members for the actual implementation process. Once again, the team consisted of only the best people, representing a cross-section of Cisco’s business community. Cisco’s policy emphasized that for those working on the implementation, it was a short term project, and did not represent a change in career. At the start of the implementation, the team members were split up into five ‘tracks’ or process area teams, each relating to a functional area Order Entry, Manufacturing, Finance, Sales/Reporting, and Technology (Exhibit 5). Each track consisted of a Cisco information systems leader, a Cisco business leader, business and IT consultants from either KPMG or Oracle, and personnel from Cisco as team members. The five tracks were managed from a ‘Project Management Office’, which consisted of Cisco’s business project manager, and KPMG’s project manager. Monitoring the Project Management Office was an Executive Steering Committee that consisted of the senior most executives from Cisco, KPMG, and Oracle. The strategy behind using the steering committee was to relieve the development team of the need to intervene directly in the management of the project. Implementing Oracle in Iterative prototyping The Cisco team employed ‘rapid iterative prototyping’ (Exhibit 4A, Exhibit 4B) as the development technique for the implementation of the ERP. Normally, ERP is implemented using the sequentially model minus the coding (Exhibit 3). This is because Cisco wanted to keep open the provision to change Oracle codes to suit its purpose. This customized coding was not offered by other vendors. Oracle, being new and promised with marketing assistance from Cisco has no option. The implementation was broken into a series of phases called ‘conference room pilots’ (CRPs). The purpose of a CRP was to build on previous work, to develop a deeper understanding of the software and how it functioned within the business environment, 6 Similar to Rapid Application Development and Throw away Prototyping. 7 ERPs are ready to implement software, already coded. Copyright © 2005 Avimanyu Datta. Page 5 Case Prepared by Avimanyu Datta, Team Leader, ICFAI Business School Research Center and to better configure the software to suit the company’s needs. (Exhibit 6 shows how Cisco blended waterfall model with iterative prototyping from Systems Analysis to final delivery) The first CRP, CRP0 (Exhibit 6), began with training the implementation team, and setting up the technical environment for the implementation. Here, two parallel efforts were launched. The first effort involved training Cisco’s team members on the Oracle applications, through two days of intensive training. While most ERP implementation requires six months to analyze the system for six months, CISCO spent only two days, employing 40 people in analyzing the system. In addition the five day training session that was required to know the application suite was reduced to two sixteen-hour days. In this stage 80% of the requirements were spelt out. The rest 20% of customized requirements were spelt later. Simultaneously, the second effort worked on setting up the Oracle applications. The training of the entire team was completed within a two-week period. Following this, the team members spent two more days in intensive group meeting to decide on the appropriate data settings for the hundreds of parameters embedded within the Oracle software, that were to be set according to their particular business needs. One week after this meeting, CRP0 was successfully completed. It implemented the capacity to take a Cisco order all the way through the company’s business process from its quotation to payment. The implementation of CRP0 brought forward an important fact that the initial target of implementation with low customization of the Oracle software would not be successful. This made the process more time consuming. Thus, CRP1 (Exhibit 6) was started, building on the lessons learned with CRP0. The goal of this phase was for each of the five tracks/ modules (Exhibit 5), to make the system work within their specific area. This was the focused group geared toward customizing the system. Oracle had to modify some a chunk of existing codes to match Cisco’s customized requirement. Cisco’s promise of future marketing partnership left Oracle with no option. Team members documented the purpose for and procedures used to complete every process, and problem issues were addressed in weekly three-hour meetings with the Project Management Office. Proceeding through this phase, the team realized the fact that there were huge numbers of business processes that the software could not support. The implementation team developed a means for categorizing and evaluating each instance separately. All modifications were classified as red (extremely critical), yellow (critical), or green(moderate). In the end, 30 developers spent three months just to modify Oracle to support the Cisco business process. In addition, the implementation team realized that the Oracle package would not adequately support, the after sales support needs of the company. So the team 8 Systems Analysis is the first stage of the System Development Life Cycle (SDLC). It is also the most critical making the system correct for the business needs. Everything from basic 9 Data settings mainly refers to the domain of values a data is supposed to accept. For instance the data under item “Products” for Cisco would be routers, Switches etc. For Amazon it would be books, CDs, DVDs, games etc. 10 Code modification is uncharacteristic of ERP implementation. Bute here Cisco got better off Oracle. Copyright © 2005 Avimanyu Datta. Page 6 Case Prepared by Avimanyu Datta, Team Leader, ICFAI Business School Research Center launched a parallel effort to evaluate and select a separate service support package. The service package was selected and implemented within the same schedule as the oracle package. The beginning of CRP2 (Exhibit 6) saw the most difficult part of the implementation. Cisco’s initial target of low customization was given up, and a highly customized system was built in the end. It included major modifications in the Oracle software, incorporated the new after-sales support package, and implemented a new approach for data communication via a data warehouse. The feature included capability to report historical and future data in the integrated data warehouse. The scope change involved further adjustments to Cisco’s resource structure for the project. The final goal of CRP2 was to begin testing the system, to see how well it could stand up to the processing load and transaction volumes required to support Cisco’s growing business. CRP3’s focus was on testing the system with full transaction load and assessing the date when the system could start operation. All these were accomplished within the initial schedule. The initial instability and its correction On starting operation, the new system proved disturbingly unstable. On an average, it went down nearly once a day. The primary problem was with the hardware architecture, and secondarily with the software that could not handle the transaction volume required in the Cisco environment. Cisco realized that their mistake was that they had not tested the system with a big enough database. They had run individual processes sequentially, with only a partially loaded database. After ‘cutover’, when all the processes were running together, over a fully converted database, the system lacked the capacity to process the required load. The hardware contract Correcting the inefficiency meant purchase of additional hardware, thus increasing the project expenditure for Cisco. Here, Cisco pulled out an unusually attractive deal. Deal was to purchase a promised capability, rather than a specific configuration. In the end, all the pieces fell into place with the new system fulfilling the promise of supporting the rapid growth that Cisco was expecting in the years to come. As a result, the responsibility for fixing the hardware problems fell completely on the hardware vendor. Stabilization The technical problems associated with Oracle proved short lived. According to the same source, strong vendor commitment from Oracle, and the hardware vendor, and experienced support from KPMG lead to an eventual stabilization and substantial improvement in performance, after three months. Result Cisco was extremely successful in terms of the overall performance of the system. With only a few customizations, the system was working well. The only trouble that had plagued the implementation was the capacity, which was later rectified with a match winning contract with the hardware vendor. The complete system performance was worked out when the project team did its CRP design and testing. By building on the Copyright © 2005 Avimanyu Datta. Page 7 Case Prepared by Avimanyu Datta, Team Leader, ICFAI Business School Research Center previous version of CRP, the team was able to optimize its functionality. At the end of the implementation, the cutover was successful because of strong coordination between each company involved. The overall cost expectancy was met. The goal of the project was to have the budget at or below $15 million. Cisco reached this goal and also decided to provide its hard working implementation team with a bonus pool of over $200,000. Lessons learnt Blending the stability of Iterative nature of ERP implementation (Exhibit 3) and the dynamics of Rapid Application Development (Exhibit 4a and Exhibit 4b) Cisco was able to get its system operational by 9 months and within its budget. Such blending was possible mainly of two reasons. Firstly, Cisco received top management support (the key to successful ERP implementation, Exhibit 2) from the very beginning of the project. The quick and concise execution of selection and planning partnered with strong backing by senior management were the success drivers of the entire project. Top management support reduces stakeholder problems that Secondly, the teams from Cisco, KPMG and Oracle blended as one. This enabled perfect diffusion (Annexure 1) of knowledge as show in some of the latest management thoughts. However, luck would not be without its part in the project’s success. The success of Cisco in this project is attributed to the combination of luck factors that fell into place during its implementation. They are (a) timing, (b) access to resources. The strong relationships formed for the project were the result of good timing. For instance Oracle had to prove its worth in a market hugely ruled by SAP America. This timing gave Cisco a huge bargaining power over Oracle. Also Cisco promoted Oracle with marketing assistance for Oracle’s upcoming products and its ERP. The timing put Cisco in a position where Oracle needed more that Cisco needed to give. One important aspect of this timing was Cisco modifying Oracle’s codes to match its customized requirements. Such timing is impossible to replicate. Also, it can be argued that Cisco being in the telecom business enabled its partners, Oracle and KPMG to access the best technical resources for the project. This reduced the cost of the project. LeadershipFormation of a cohesive team that was fast in its acting led to the success of the project. Besides, the team got indispensable support from the Top Management. PlanningThe initial planning and analysis of project scope, partners, and vendors was the single reason that the project was a success. Cisco found the best people for the job and what they received in return was the unsurpassed service from each of their partners. Contract negotiationContract negotiation is always an underlying factor in any project’s success. In the Cisco case a great contract born of great opportunity saved the company thousands of dollars and perhaps months of system configuration during the late stages of the implementation. The timing of the contract negotiation gave Cisco a huge bargaining power over Oracle. Also Cisco promoted Oracle with marketing assistance for Oracle’s upcoming products and its ERP. The timing put Cisco in a position where Oracle needed more that Cisco needed to give PersistenceDuring the choosing of parameters and system configuration the company decided to go 80-20 on parameter settings and cram months of research and choices Copyright © 2005 Avimanyu Datta. Page 8 Case Prepared by Avimanyu Datta, Team Leader, ICFAI Business School Research Center into two days. The project had been going extremely well up to this point and if Cisco would not have rushed this as much they would not have encountered the same amount of problems with scope and capacity if they simply would have taken more time and been persistent with their planning. The Road Ahead and Key Questions The successful implementation showed that Oracle ERP system could run manufacturing companies with few customizations. This implementation should pave way how manufacturing business and most other types of business should rethink concepts and theories attached to information systems project management. With the success of this project, Oracle ERP package could count on its way to become an industry standard. The project also paved path in Oracles favor. Cisco agreed upon helping oracle to market their latest newest releases to potential customers. Cisco would allow prospective customers to view the processes and see the reasoning behind the Oracle system. Further, if the variables other that luck are weighed significantly then this project could add as value in discussing the parameters of successful Information Systems development Projects. Key Questions Questions 1 through 3 are direct and pertain to the scope of the case. Question 2 asks whether Cisco could repeat its success. This would help in analyzing the significance of Luck and timing as opposed to Cisco’s elegant project management techniques. The last question asks whether other firms could replicate Cisco’s performance. Although it might be difficult for most company’s considering Cisco’s uniqueness. Whether other companies would be able to replicate Cisco’s success depends how much support the top management would tender. Also, how the vendor and the customer view each other from a long term standing. The questions are: 1. How partnerships determine the success of projects? 2. How important was project timing and luck contributes to the success or the project? 3. How important is contract negotiations in determining a project success? 4. Can Cisco repeat its success? 5. Can other firms replicate the success? Copyright © 2005 Avimanyu Datta. Page 9 Case Prepared by Avimanyu Datta, Team Leader, ICFAI Business School Research Center EXHIBIT 1 ERP VENDORS People Soft SAP America Oracle 1995 total Revenues $210 million $ 1.1 billion $291 million % from Software 57% 74% 54% % from services 43% 26% 46% 1994-1995 total revenue growth 94% 88% 81% Revenues outside United States 17% 67% 60% Headquarters Pleasanton, California Walldorf, Germany Redwood Shores, California Employees 2,400 8,500 25,000 Customers 1,300 8,500 25,000 Strengths 1. Customer service 2. Excellent functionality 3. Growing network of partners 1. Broadest functionality in integrated product suite. 2. Size and market presence 3. Broad support from partners 1. Large installed base of Oracle Customers 2. Global presence 3. Link to other Oracle technologies Weaknesses 1. Aging Technology 2. Poor—cross product integration 3. credibility in non-HR products 1. Long complex implementation. 2. backlash against high cost 3. Inflexible 1. Limited to HR functionality. 2. Weak Service partner program 3. limited to Oracle database Copyright © 2005 Avimanyu Datta. Page 10 Case Prepared by Avimanyu Datta, Team Leader, ICFAI Business School Research Center Copyright © 2005 Avimanyu Datta. Page 11 EXHIBIT 2 Model of Successful ERP Project management. Source: Aladwani, A.D. (2001). Change Management for successful ERP implementation. Business Process Management Journal Vol.7 No. 3 P.266-275. Retrieved July 2, 2005 from web.njit.edu/~jerry/OM/OM-ERP-Papers/ERP-10-Success.pdf Case Prepared by Avimanyu Datta, Team Leader, ICFAI Business School Research Center Copyright © 2005 Avimanyu Datta. Page 12 EXHIBIT 3 FIVE PHASES OF ERP IMPLEMENTATION maintenance system Strategy and Planning: Requirement Analysis Design and Blueprint: Requires high interaction with end-users. The internal team and the consultant must work together Software configuration Data migration: involves populating the new ERP master file with data from existing Application customization: Similar to Corrective, Adaptive, and Perfective Source http://www.networkworld.com/research/2004/0202offshoreside1.html Case Prepared by Avimanyu Datta, Team Leader, ICFAI Business School Research Center EXHIBIT 4A RAPID APPLICATION DEVELOPMENT (EXPLANATION) In the Rapid Application Development (RAD)Prototyping approach, instead of preparing written design specifications which include drawing screen designs and report layouts on paper prior to actually building them with the development tools, they are actually painted via the development tools. Thus ,the two processes are combined into one. An iterative process is used to refine the design during the build process. A prototype module is defined at a high level. The screen/report/module is then built. The user reviews the prototype module and indicates changes or additional features needed. These are incorporated into the next iteration of the prototype and the process continues. The physical specification is achieved by developing a dynamic model of the application. Developers and users work together to produce a functional prototype which models the look and feel of the application. Prototypes are reviewed by project teams consisting of developers and end users. The functional prototypes are refined by continuous review until the look and feel is exactly what the end users require, and are then used to model the business processes. This iterative refinement is then called the design prototype, where the business rules are investigated, refined and consolidated. It is important to note that with RAD many different types of activity are taking place concurrently. The cyclic process comprises quadrants for identifying, agreeing, creating and reviewing the prototype. Each iteration will move the prototype from investigation through refinement on to consolidation. Development teams comprising of IT staff and users must be empowered to make decisions about functionality. The focus is on delivering the optimum business solution. Decisions and trade-offs have to be made between new functionality elicited through the iterative prototyping process and less important original functionality which may have to be excluded because of time constraints. Iterative development within a time window (‘timeboxing’) is a very powerful way of developing the minimum acceptable best fit business solution rapidly. Source: http://www.itmweb.com/essay520.htm http://www.dep.state.pa.us/dep/deputate/oit/SDM/inHTML/HtmlFiles/SDM/StyleGuide/RapidApplicationDe velopment.htm Copyright © 2005 Avimanyu Datta. Page 13 Case Prepared by Avimanyu Datta, Team Leader, ICFAI Business School Research Center Copyright © 2005 Avimanyu Datta. Page 14 EXHIBIT 4B RAPID APPLICATION DEVELOPMENT (DIAGRAM) JAD is Joint Application Development where the end users and the developers meet to specify rough list of specifications. Usually it compromises 80% of the requirements requiring 20% of effort. The rest 20% customized solutions are generated through focused group sessions. Source: Maner, W. (1997). Rapid Application development. Bowling Green State University Retrieved August 2, 2005 from http://odl-skopje.etf.ukim.edu.mk/UML-Help/html/01day3.html#67561 Case Prepared by Avimanyu Datta, Team Leader, ICFAI Business School Research Center Copyright © 2005 Avimanyu Datt EXHIBIT 5 ORGANIZATIONAL STRUCTURE OF THE ERP OMPLEMENTATION Executive Steering Committee comprised Management from Cisco, Oracle and KPMG Monitored the Progress of project Management office (PMO)